Document VSEARCH scaling and its flat-scan ceiling - #57

Thanks for writing this up. The table is what people need before they pick RAMen for a big collection. The 664 B/op checks out too: I added up the allocations in the code and they come to exactly 664, independent of n. Two sentences overclaim, though, and docs are where I'm strictest.

1. "The scan is memory-bound … faster arithmetic does not lower the ceiling." I don't think it is. 100k × 768 × 4 bytes is 307 MB in 70 ms, about 4.4 GB/s, well below memory bandwidth. The dot product adds into a single float64, so each add waits for the previous one, and 70 ms works out to roughly one add latency per element. More accumulators or SIMD would likely cut the constant 2–4x. That's worth knowing, and it's the opposite of what the sentence says. Suggested:

Times vary with hardware (a laptop-class i7 measured ~114 ms at 100k); the linear shape and the flat allocations do not. Tuning the inner loop can lower the constant, but not the growth: every query still touches every vector, so only a smaller collection or an index changes the curve.

2. "A few percent of what a hit saves." At 100k entries that's a 70 ms lookup against a few-hundred-ms LLM call, so 10–25%. Every miss also pays the lookup on top of the model call. Suggested:

For the semantic cache this is rarely the bottleneck: up to around 10k entries a lookup is single-digit milliseconds, small next to an LLM call. Past that, the lookup cost becomes visible — misses pay it too — and the same ceiling applies.

Optional, if you want them:

• One line noting this is in-process Collection.Search, with no network or RESP.
• VSEARCH holds the shard read lock for the whole scan, so at 100k, writes to that collection's shard wait about 70 ms.